API breakage checks (Griffe)

Result: Passed

Action log

One other design question related to this, plugins already support commands.

Would using this already-existing mechanism suffice for this use case? Or is there some other functionality that is needed that is not yet included in commands. I'm just thinking about whether we can keep the schema simple.

@neubig This assumes the existing support of commands. What it provides in addition is that it allows a plugin to declare which of the commands should be called when we are using the in plugin in an auto-start launch scenario. The auto-start launch scenario probably doesn't apply to CLI, except perhaps in a headless case, but it is relevant for Cloud when customers are building complex solutions that involve many skills but which are kicked-off via REST API and do not expose the conversation to end-users.

@enyst You are correct that it would be more flexible to have a plugin declare an initial message rather than an entry point command but constraining it to the command does two things:

1. It prevents users from a bad-practice of loading up the initial message with content which is more appropriate for a command or skill file. My thinking is that it is better to constrain to good practices initially and widen flexibility if needed later.

2. It makes it easier to deal with edge case scenarios where multiple plugins are specified all with auto-start and entry points because we can express behavior clearly in terms of how the commands are invoked--serially, parallel, all at once, subagents or not, etc.

Agent server REST API breakage checks (OpenAPI)

Result: Passed

Action log

@enyst @neubig I've added additional context to the PR description. Any remaining concerns?

You are correct that it would be more flexible to have a plugin declare an initial message rather than an entry point command but constraining it to the command does two things:

1. It prevents users from a bad-practice of loading up the initial message with content which is more appropriate for a command or skill file. My thinking is that it is better to constrain to good practices initially and widen flexibility if needed later.

No, sorry, we would not load up the initial message with content of a command / skill file.

Just the command, not its content: e.g.

• user chooses a plugin, or it was already installed; and starts a conversation
• user tells the agent: "tell me the /weather in Tokio"

That's all they should need, right? They don't need to insert the contents of the "/weather" skill. Instead, we already do automatically insert the contents?

Edited to add: TBH that might be a bad example. Maybe the way commands should work is that it starts the message. Like people typically expect them, e.g. "/review but be nice okay?"

If I understand correctly, and please correct me if not, what this PR would do is that:

• same happens, plugin must be loaded somehow (maybe from start) and user wants to start conversation
• so they say "tell me the time in Tokio".

But we inserted "/weather" in the plugin source, so we execute "/weather" even if the user wanted the time?

Just the command, not its content: e.g.

user chooses a plugin, or it was already installed; and starts a conversation
user tells the agent: "tell me the /weather in Tokio"

That would be the flow for a normal conversation and you could use the initial message that is already part of the Cloud API for that--though I suppose we'd need to add some logic in another PR that would register the entry-point command with just the /weather and not /weather:now part. That certainly makes sense to do. I just hadn't envisioned it as part of this PR, though it certainly could be.

What I DID have in mind is to allow a plugin to launch with no initial message at the press of a button and have the agent start working.

What I DID have in mind is to allow a plugin to launch with no initial message at the press of a button and have the agent start working.

Sure, please let me elaborate, I don't think I meant differently, sorry for the confusing examples. 🤔

My point is, any conversation has an initial message. I mean, the LLM request/responses array always needs an initial message

• can't send to the LLM an empty string
• can't send just the system prompt
• we always send system+initial message.

So, it seems to me, at the press of a button, the application should insert "/weather" or "/weather:now" or whatever it likes, in the place of the initial message, instead of opening the conversation tab with an input field waiting for the user. It just starts.

From the user perspective, it's exactly "I pressed a button, the conversation just started, and it does weather things"

From the backend perspective, the conversation started with the initial message "/weather" or "/weather:now", so it does what is supposed to do in that case. Please tell if I misunderstand?

My point is, any conversation has an initial message

Exactly. So we are on the same page.

So in an auto-executing plugin scenario, some system will construct the initial message from the plugin metadata. I am arguing we don't need the plugin to declare an initial message if it has commands and can declare the entry-point command. That way the message is always part of a skill and not part of a new "initial message" plugin metadata which creates ambiguity for newly initiated plugin authors.

[Automatic Post]: It has been a while since there was any activity on this PR. @jpshackelford, are you still working on it? If so, please go ahead, if not then please request review, close it, or request that someone else follow up.